Method and System to Automatically Adapt Web Services from One Protocol/Idiom to Another Protocol/Idiom

ABSTRACT

Disclosed are embodiments of a method and system to convert an existing web services request from a first web services implementation type to a second web services implementation type. Example implementation types include SOAP-based and Representational State Transfer (RESTful). Conversion may be achieved through use of a generic web services adaptor. The generic web services adaptor can provide a plurality of interface types and convert requests to a request type supported by an existing web service provider endpoint. In some embodiments, requests not requiring a conversion may be forwarded directly to an existing web service provider endpoint.

CROSS REFERENCE TO RELATED APPLICATIONS

This disclosure is a continuation in part of U.S. patent applicationSer. No. 12/650,107 entitled “A Method and System to Automatically AdaptWeb Services from one Protocol/Idiom to Another Protocol/Idiom” byVincent Kowalski filed 30 Dec. 2009 and which is incorporated byreference herein in its entirety.

BACKGROUND

This disclosure relates generally to the field of web services. Moreparticularly, but not by way of limitation, this disclosure refers to amethod of adapting web services based on different implementations(e.g., SOAP or RESTful) to an implementation style other than that forwhich a web service was originally provided.

In the web services world, Representational State Transfer (REST) is adesign architecture that embraces a stateless client-server architecturein which the web services are viewed as resources and can be identifiedby their Universal Resource Locators (URLs). Web services clients thatwant to use these resources may access a particular representation bytransferring application content using a small globally defined set ofremote methods that describe the action to be performed on the resource.

SOAP used to be an acronym that stood for Simple Object Access Protocol.However over time the acronym was dropped and there is now no officialmeaning attributed to the name SOAP. As used herein, SOAP is built ontop of eXtensible Markup Language (XML). SOAP is a protocol in whichoperations (similar to functions or subroutines in standard programminglanguages) are invoked. This invocation typically causes animplementation on a server (e.g., SOAP web services endpoint) to executesome code (e.g., business logic) and return a result. SOAP can be viewedas a “request-response” type of model.

Today web services are not standardized such that they may interact withrequests from a plurality of protocols or design architectures. Forexample, SOAP represents one type of web service prevalent today andRESTful represents a different type of web service. It is also clearthat both SOAP and REST based web services are going to coexist in theworld for the foreseeable future. Given this existing lack ofstandardization, existing web services may be exposed only for webapplications interacting in a different manner than may be desired by aweb developer.

To overcome these and other limitations it is desirable to provide ageneric web services server (e.g., man in the middle adaptor) to allowmore flexibility to web application programmers.

SUMMARY

Disclosed are methods and systems to allow a web application requestinginformation based on a particular type of web services interface (e.g.,SOAP or RESTful) to have that request adapted/converted into anothertype of web services request and sent to a corresponding already exposedinterface. For example, a web application desiring to communicate withan existing SOAP web service via a RESTful interface could have itsrequest converted automatically from RESTful to SOAP and delivered tothe existing SOAP interface. This adaption or conversion may also beapplied for an existing SOAP web services interface such that a SOAPclient may communicate, indirectly, with an exposed RESTful interface.Thus, existing web services may be more easily consumed without havingto (re)design and expose an interface for each type desired by clientweb applications. Also, responses from the exiting web service may beconverted back to the paradigm expected by the web application clientbefore being returned.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows, in block diagram form, an exemplary client communicativelycoupled to a web application server, a generic web services adaptor, anda web service provided by an endpoint.

FIGS. 2A-B show an example web services request/response for a RESTfulweb service and SOAP-based web service.

FIG. 3 shows, in flowchart form, an embodiment of converting a SOAP webservice request into a RESTful web service request.

FIG. 4 shows, in flowchart form, an embodiment of converting a RESTfulweb service request into a SOAP web service request.

FIG. 5 shows, in block diagram form, a simplified computer networkcomprising a generic adaptor architecture configured to performconversion of web services requests from one interface type to another.

FIG. 6 shows, in block diagram form, an embodiment of a computer networkcomprising a generic adaptor which in turn comprises a plurality ofadaptors for converting web services requests from one interface type toanother

FIG. 7 shows, in block diagram form, an exemplary computing devicecomprising a program control device.

DETAILED DESCRIPTION

Methods and systems to automatically convert from one web servicesimplementation type to another web services implementation type aredisclosed. In order for a client and a server to properly work togetherthere must be a consistent interface between the two. That is not to saythat both applications executing in one or more computers must have thesame interface type for communication. However, if a client and a serverare not communicating via the same interface, an adaption interface mustbe provided. In particular, if a client computer is configured tosend/receive a particular interface type (e.g., SOAP/REST) and a servercomputer is configured to answer requests from a different interfacetype, then some adaption or conversion must be performed before theclient can properly communicate with the server. Disclosed is a methodand system to expose and convert an existing web service, provided by anendpoint, to a different interface type and make the new interfaceavailable from a computer executing a generic web services adaptor.

Disclosed are embodiments of a generic adaptor for web services. Asdiscussed above, prior art implementations require a developer of a webapplication to code the web application for a specific type of exposedweb services interface. By implementing a generic web services adaptor,web application developers and others may code an application to anyimplementation supported by the generic adaptor without regard to theactual implementation of the existing exposed interface of a webservice.

As a result of the ability to perform conversion, the adaptor mayprovide a plurality of interfaces for clients (e.g., web applications)configured to send/receive in either the original interface or the newlysupplied and exposed interface of a different type. The embodimentsdisclosed herein are confined to SOAP and REST web services. However,those of ordinary skill in the art will recognize that the conceptsdisclosed herein may also be applicable to other web services interfaceimplementation types (e.g., eXtensible Markup Language—Remote ProcedureCall (XML-RPC), JavaScript Object Notation (JSON), Hypertext TransferProtocol (HTTP), etc.).

Referring now to FIG. 1, a high level block diagram of an interconnectedcomputer system 100 is shown. Client computer 110 represents a computerwhich executes a web browser and may connect (via a Universal ResourceLocator (URL)) to web application server 130. In this example, webapplication server 130 is a consumer of web services provided by a webservices provider (endpoint) 140. Communication between client computer110, web application server 130, and endpoint 140 takes place acrossnetwork 120. A request across network 120 for a web service fromendpoint 140 will typically be an encapsulated “message.” The messagemay allow for sending/receiving one or more pieces of information. Thisencapsulation may be accomplished in many ways, including a SOAP stylerequest or a RESTful style request, among others. In other words,typical requests across a network are bundles of information such thatmultiple interactions (for a discrete piece of information) between aweb application executing on web application server 130 and endpoint 140may be minimized.

Network 120 represents a communication coupling between computers (e.g.,110, 130, 135 and 140). Network 120 may be either wired or wireless or acombination thereof. Examples of network 120 include, but are notlimited to, a LAN, WAN, Internet, Intranet and the like. Note thesegregation of functions described is logical and not physical.Therefore, it is possible for any combination of a client application, aweb application, a generic web services adaptor, and a web servicesprovider (endpoint) to coexist on the same physical computer withoutactually sending data across a network such as network 120. Further, thedesignation of client versus server may exist between many levels ofthis logical segregation. Therefore, client generally refers to arequesting application/computer and server generally refers to anapplication/computer servicing the request. Also, a client applicationand corresponding server application may actually execute on the same ordifferent physical computers.

If web application server 130 desires a SOAP interface to a web serviceon endpoint 140 and endpoint 140 already has an exposed SOAP interface,then server 130 can communicate directly with endpoint 140. However, ifweb application server 130 desires a RESTful interface to this sameexposed SOAP interface then, as explained above, it cannot communicatedirectly. In one disclosed embodiment, this situation may be overcome byhaving web application server send its RESTful request to generic webservices adaptor server 135. Generic web service adaptor 135 can thentranslate or adapt the request from a RESTful request to a SOAP stylerequest and forward the request to the already exposed SOAP interface onendpoint 140. After processing the SOAP style request, endpoint 140 willrespond to server 135 and server 135 may translate the response to aformat expected by original requesting computer 130. In this embodiment,neither computer 130 nor endpoint computer 140 must be made aware of, orbe concerned with, the type of interface they are servicing orconsuming.

To aid in the understanding of this disclosure the following definitionsare provided:

WSDL: Web Services Definition Language (WSDL) is, in general, an XMLformat for describing network services as a set of endpoints operatingon messages containing either document-oriented or procedure-orientedinformation. The operations and messages are described abstractly, andthen bound to a concrete network protocol and message format to definean endpoint. Related concrete endpoints are combined into abstractendpoints (services). WSDL is extensible to allow the description ofendpoints and their messages regardless of what message formats ornetwork protocols are used to communicate. WSDL is typically used todefine and describe the interfaces of SOAP-based web services.

WADL: Web Application Description Language (WADL) is described in aspecification promulgated by the World Wide Web Consortium (W3C). WADLis designed to provide a machine process-able description of suchHTTP-based Web applications. An increasing number of Web-basedenterprises (e.g., Google®, Yahoo®, Amazon®, and Flickr®) are developingHTTP-based applications that provide programmatic access to theirinternal data. (GOOGLE is a registered trademark of Google Inc.,Mountain View Calif. YAHOO and FLICKR are registered trademarks ofYahoo! Inc., Sunnyvale Calif. AMAZON is a registered trademark ofAmazon.com Inc., Seattle Wash.) Typically these applications aredescribed using textual documentation that is sometimes supplementedwith more formal specifications such as XML schema for XML-based dataformats. WADL may be used to define and describe the interfaces ofRESTful web services.

XML: eXtensible Markup Language is a set of rules for encoding documentselectronically. It is defined in the XML 1.0 Specification produced bythe W3C and several other related specifications; all are fee-free openstandards. XML's design goals emphasize simplicity, generality, andusability over the Internet. It is a textual data format, with strongsupport via Unicode for the languages of the world. Although XML'sdesign focuses on documents, it is widely used for the representation ofarbitrary data structures, for example in web services. Each of thestandards for WSDL, SOAP and WADL described herein are expressed in XML.

XSLT: eXtensible Stylesheet Language (XSL) Transformation is adeclarative, XML-based language used for the transformation of XMLdocuments into other XML documents. The original document is notchanged; rather, a new document is created based on the content of anexisting one. The new document may be serialized (output) by theprocessor in standard XML syntax or in another format, such as HTML orplain text. XSLT is often used to convert XML data into HTML or XHTMLdocuments for display as a web page: the transformation may happendynamically either on the client or on the server, or it may be done aspart of the publishing process. XSLT is also used to translate XMLmessages between different XML schemas, or to make changes to documentswithin the scope of a single schema, for example by removing the partsof a message that are not needed.

Web Application: a web application (webapp) is an application that istypically accessed via a web browser over a network such as the Internetor an intranet. The term may also refer to a computer softwareapplication that is hosted in a browser-controlled environment (e.g., aJava applet) or coded in a browser-supported language (such asJavaScript) and reliant on a common web browser to render theapplication executable. Web Applications are usually segregated intological layers called “tiers,” where every tier is assigned a role. Forthe examples of this disclosure, it is assumed a webapp is divided intoa client side tier (presentation) communicating directly with a webbrowser and a server side tier, providing the functionality (businesslogic) of the application, communicating with web services. However, oneof ordinary skill in the art will recognize that a webapp may beimplemented as a many-tier architecture.

Referring now to FIGS. 2A-B, an example web service request/response foreach of REST and SOAP are shown. This example web service operationwould get the stock price for a particular stock symbol. As those ofordinary skill in the art will recognize, REST is actually thearchitecture underlying the Web. Therefore, when comparing REST withSOAP (which is really a protocol, not an architecture) we classify theRESTful web services based on different idioms. RESTful web services areinvocations of functionality across the Web that comply with RESTarchitecture. In contrast, SOAP invocations are done by communicatingthe function semantics and syntax (i.e., the operation and parameternames) with an endpoint. To make a REST request a user navigates to aresource. This navigation is usually accomplished by an HTTP operation,typically (although not exclusively) a GET. This is a significantdistinction between REST and SOAP.

Returning now to FIG. 2A, a RESTful request is simply a URL as shown inelement 210. The corresponding RESTful response in XML is shown inelement 220. FIG. 2B shows the corresponding SOAP-based response andrequest. Element 250 shows the request is an XML based SOAP envelop andelement 260 shows an example response that may be provided by aSOAP-based web service. Note the syntax and URLs used here are forillustration purposes only.

Explained next are sample embodiments of a conversion process. First, anexample conversion of a SOAP interface to a RESTful interface isdescribed. Second, an example of classifying a RESTful web service andconverting the classified RESTful web service to a SOAP interface isdescribed. Further details of this classification and conversionmethodology can be found in U.S. patent application Ser. No. 12/650,107entitled “A Method and System to Automatically Adapt Web Services fromone Protocol/Idiom to Another Protocol/Idiom” by Vincent Kowalski.

Referring now to FIG. 3, an example process 300 for converting from aSOAP interface style to a RESTful interface style is shown. Process 300begins at block 310, which depicts an existing SOAP interface and itscorresponding WSDL description. WSDL is implemented in XML. Therefore,an XSLT transformation may be applied (block 320) to produce a WADLdescription of the interface (block 330). Utilizing the created WADL anew RESTful web services interface may be generated (block 340).Finally, the new RESTful web service interface may be made available(exposed) on a web server at block 350.

Referring now to FIG. 4, an example process 400 for converting from aRESTful interface tyle to a SOAP-based interface style is shown. Process400 begins at block 410 with an existing RESTful Web Service.Classification of the exposed interface is performed at block 420. Ifthe exposed interface is unclassifiable, the NO prong of 430, ahand-coded WADL may need to be created as represented by block 450. Ifthe classification is possible, the YES prong of 430, then anauto-translated WADL may be created at block 440. In either case theWADL is processed by applying an XSLT transformation (block 460) toproduce a WSDL description at block 470. Finally, at block 480, aSOAP-based Web Service interface may be made available on the webserver.

Referring now to FIG. 5, sample architecture 500 comprises a webservices endpoint 510 providing a web service for “stock quotes,” webservices client 530 configured to make SOAP requests, web servicesclient 520 configured to make RESTful requests and generic web servicesadaptor 540. In this example, Stock Quote Service Provider (Endpoint)510 originally provided a SOAP interface and cannot service requestsfrom RESTful clients such as client 520. Client 530 may make SOAPrequests and receive SOAP responses via direct communication withendpoint 510 as shown by element 535. However, for the reasons discussedabove, request/response messages 525 from client 520 require conversionbefore client 520 may take advantage of the Stock Quote Service fromendpoint 510. Therefore, in this example, conversion is performed bygeneric web services adaptor 540 exposing a RESTful interface 560 andexecuting adaptor function 565. In this example, client 520 requests(525) a stock quote from RESTful interface 560. RESTful interface 560(and generic web services adaptor) is not required to provide thebusiness logic supporting a stock quote service. RESTful interface 560receives the request and passes the request to adaptor function 565.After converting the request into a style acceptable by endpoint 510,the request is forwarded (570) to endpoint 510 where all business logicthat implements the stock quote service may be performed. The businesslogic of endpoint 510 is executed as if the request originated from aSOAP based client. Upon completion of the business logic, endpoint 510responds (570) with a SOAP response to generic web services adaptor 540.Conversion of this SOAP response may then be performed by adaptor 565resulting in a RESTful response (525) as required and expected byoriginal requesting client 520. In this manner, client 520 may utilize aweb service provided by endpoint 510 without an update to eitherimplementation because of generic web services adaptor 540.

Building upon the example of FIG. 5 and referring now to FIG. 6, samplearchitecture 600 comprises a plurality of endpoint web service providers610 and 611, another embodiment of web services generic adaptor 640, anda plurality of web services clients such as 620 and 630. In thisembodiment, generic web services adaptor 640 comprises a RESTfulinterface 660 and adaptor 662 configured to convert RESTful basedrequests into SOAP based requests. Generic web services adaptor 640 alsocomprises a SOAP interface 665 and adaptor 667 configured to convertSOAP based requests into RESTful based requests. RESTful requests arriveat generic web services adaptor computer as indicated by element 641 andSOAP requests arrive as indicated by element 651. Upon receipt, RESTfulrequests (641) for a particular web service can be passed (642) directlyto web service endpoint 610 exposing a RESTful interface or requests canbe converted by adaptor 662 into SOAP based requests and passed (643) toan endpoint 611 exposing a SOAP interface. Additionally, upon receipt ofSOAP based requests (651) for a particular web service, requests can bepassed (652) directly to web service endpoint 611 exposing a SOAPinterface or requests can be converted by adaptor 667 into RESTful basedrequests and passed (653) to an endpoint 610 exposing a RESTfulinterface. Thus, in this embodiment all requests from clients aredirected to generic web services adaptor 640 and web applicationdevelopers may be provided with greater flexibility because they are notrequired to concern themselves with the actual type of web serviceinterface exposed by a supported web service provider endpoint.

Note architecture 600 is shown with only two web services clients andtwo web service provider endpoints for simplicity. Any number of webservices clients or endpoint service providers may be supported on anynumber of computers. Also, it is possible for a single computer toprocess activity associated with any combination of activities reflectedin elements 610, 611, 620, 630 and 640. That is, a single computer canbe concurrently configured to request web services via a SOAP interfaceand a RESTful web service (likely different web services provided bydistinct service provider endpoints).

Based on the disclosed embodiments, generic web services adaptor mayprovide even further flexibility for web application developers. Forexample, generic web services adaptor may be configured to provideeither complete or partial business logic for web service providerendpoints that have been decommissioned. Also, generic web servicesadaptor may be configured to redirect either full or partial requestsfor a web service to a web service provider other than that originallyrequested. This may be done to either support a request more efficientlyor to satisfy the request in a manner other than sending it to theoriginally requested web service provider. Of course, security and dataintegrity may need to be taken into account for all disclosedembodiments. Methods of implementing certain security controls are knownin the art and are not directly discussed here.

Referring now to FIG. 7, an exemplary computing device 700 is shown. Oneor more exemplary computing devices 700 may be included in a mainframecomputer (not shown) or a standard distributed computer. Exemplarycomputing device 700 comprises a programmable control device 710 whichmay be optionally connected to input 760 (e.g., keyboard, mouse, touchscreen, etc.), display 770 or program storage device (PSD) 780(sometimes referred to as a direct access storage device DASD). Also,included with program device 710 is a network interface 740 forcommunication via a network with other computing and corporateinfrastructure devices (not shown). Note network interface 740 may beincluded within programmable control device 710 or be external toprogrammable control device 710. In either case, programmable controldevice 710 will be communicatively coupled to network interface 740.Also note, program storage unit 780 represents any form of non-volatilestorage including, but not limited to, all forms of optical and magneticstorage elements including solid-state storage.

Program control device 710 may be included in a computing device and beprogrammed to perform methods in accordance with this disclosure (e.g.,those illustrated in FIGS. 5 and 3). Program control device 710comprises a processor unit (PU) 720, input-output (I/O) interface 750and memory 730. Processing unit 720 may include any programmablecontroller device including, for example, processors of an IBM mainframe(such as a quad-core z10 mainframe microprocessor). Alternatively, innon-mainframe systems examples of processing unit 720 include the IntelCore®, Pentium® and Celeron® processor families from Intel and theCortex and ARM processor families from ARM. (INTEL CORE, PENTIUM andCELERON are registered trademarks of the Intel Corporation. CORTEX is aregistered trademark of the ARM Limited Corporation. ARM is a registeredtrademark of the ARM Limited Company.) Memory 730 may include one ormore memory modules and comprise random access memory (RAM), read onlymemory (ROM), programmable read only memory (PROM), programmableread-write memory, and solid state memory. One of ordinary skill in theart will also recognize that PU 720 may also include some internalmemory including, for example, cache memory.

Aspects of the embodiments are described as a method of control ormanipulation of data, and may be implemented in one or a combination ofhardware, firmware, and software. Embodiments may also be implemented asinstructions stored on a machine-readable medium, which may be read andexecuted by at least one processor to perform the operations describedherein. A machine-readable medium may include any mechanism for tangiblyembodying information in a form readable by a machine (e.g., acomputer). For example, a machine-readable medium (sometimes referred toas a program storage device or a computer readable medium) may includeread-only memory (ROM), random-access memory (RAM), magnetic discstorage media, optical storage media, flash-memory devices, electrical,optical, and others.

In the above detailed description, various features are occasionallygrouped together in a single embodiment for the purpose of streamliningthe disclosure. This method of disclosure is not to be interpreted asreflecting an intention that the claimed embodiments of the subjectmatter require more features than are expressly recited in each claim.

Various changes in the details of the illustrated operational methodsare possible without departing from the scope of the following claims.For instance, illustrative flow chart steps or process steps of FIGS. 3and 4 may be performed in an order different from that disclosed here.Alternatively, some embodiments may combine the activities describedherein as being separate steps or combine the logical systems describedherein as being separate computers into one physical computer.Similarly, one or more of the described steps may be omitted, dependingupon the specific operational environment the method is beingimplemented in. In addition, acts in accordance with FIGS. 3 and 4 maybe performed by a programmable control device executing instructionsorganized into one or more program modules. A programmable controldevice may be a single computer processor, a special purpose processor(e.g., a digital signal processor, “DSP”), a plurality of processorscoupled by a communications link or a custom designed state machine.Custom designed state machines may be embodied in a hardware device suchas an integrated circuit including, but not limited to, applicationspecific integrated circuits (“ASICs”) or field programmable gate array(“FPGAs”). Storage devices, sometimes called computer readable medium,suitable for tangibly embodying program instructions include, but arenot limited to: magnetic disks (fixed, floppy, and removable) and tape;optical media such as CD-ROMs and digital video disks (“DVDs”); andsemiconductor memory devices such as Electrically Programmable Read-OnlyMemory (“EPROM”), Electrically Erasable Programmable Read-Only Memory(“EEPROM”), Programmable Gate Arrays and flash devices.

It is to be understood that the above description is intended to beillustrative, and not restrictive. For example, the above-describedembodiments may be used in combination with each other. Many otherembodiments will be apparent to those of skill in the art upon reviewingthe above description. The scope of the invention should, therefore, bedetermined with reference to the appended claims, along with the fullscope of equivalents to which such claims are entitled. In the appendedclaims, the terms “including” and “in which” are used as theplain-English equivalents of the respective terms “comprising” and“wherein.”

1. A method of processing a web services request on a programmable control device, the method comprising: receiving a web services request targeted for a first web services interface type; translating the web services request, on the programmable control device, to a second web services interface type; sending the translated web services request to a web services endpoint; receiving a response from the web services endpoint; translating the response to be compliant with the first web services interface type; and responding to the received web services request.
 2. The method of claim 1, wherein the web services endpoint functionality and the steps of translation are provided by a single computer system.
 3. The method of claim 1, wherein the first web services interface type is SOAP and the second web services interface type is RESTful.
 4. The method of claim 1, wherein the first web services interface type is RESTful and the second web service interface type is SOAP.
 5. The method of claim 2 wherein the RESTful web services request is classified as part of the act of translating the web services request.
 6. The method of claim 1, wherein the first web services interface type is selected from the group consisting of XML-RPC, JSON, HTTP, RESTful, and SOAP and the second web service interface type is selected from the group consisting of XML-RPC, JSON, HTTP, RESTful, and SOAP.
 7. A method of processing a web services request on a programmable control device, the method comprising: receiving, on a programmable control device, a web services request from a web services client in a first web services format and an indication of a web services endpoint; identifying the web services endpoint using the indication; determining an interface type of an exposed web service interface on the web services endpoint; translating the received web services request to be compliant with the determined interface type if the determined interface type is not already compliant with the first web services format; sending a compliant web services request to the web services endpoint; receiving a response from the web services endpoint; translating the response to be compliant with the first web services format if the response is not already compliant with the first web services format; and sending a response, compliant with the first web services format, to the web services client.
 8. The method of claim 7, wherein the functionality of the identified web services endpoint and the steps of translation are provided by a single computer.
 9. The method of claim 7, wherein the first web services format is SOAP and the determined interface type is RESTful.
 10. The method of claim 7, wherein the first web services format is RESTful and the determined interface type is SOAP.
 11. The method of claim 10 wherein the RESTful web services request is classified as part of the act of translating the received web services request.
 12. The method of claim 7, wherein the first web services format is selected from the group consisting of XML-RPC, JSON, HTTP, RESTful, and SOAP and the determined interface type is selected from the group consisting of XML-RPC, JSON, HTTP, RESTful, and SOAP.
 13. A computer readable medium comprising computer readable instructions stored thereon to cause a programmable control device to perform the method of claim
 1. 14. A computer readable medium comprising computer readable instructions stored thereon to cause a programmable control device to perform the method of claim
 7. 15. A computer system comprising one or more programmable control devices communicatively coupled to each other and to a computer network, wherein the one or more programmable control devices are programmed to: receive a web services request, from the computer network, targeted for a first web services interface type; translate the web services request, on the one or more programmable control devices, to a second web services interface type; send the translated web services request to a web services endpoint; receive a response from the web services endpoint; translate the response to be compliant with the first web services interface type; and respond to the received web services request.
 16. The computer system of claim 15, wherein the first web services interface type is SOAP and the second web services interface type is RESTful.
 17. The computer system of claim 15, wherein the first web services interface type is RESTful and the second web service interface type is SOAP.
 18. The computer system of claim 15 wherein the one or more programmable control devices is further programmed to perform the programmed acts of receiving and sending to and from a plurality of web services endpoints and web services clients concurrently and wherein the programmed act of translating a plurality of different web services interface types is also performed concurrently.
 19. A computer system comprising one or more programmable control devices communicatively coupled to each other and to a computer network, wherein the one or more programmable control devices are programmed to: receive, on one of the one or more programmable control devices via the computer network, a web services request from a web services client in a first web services format and an indication of a web services endpoint; identify the web services endpoint using the indication; determine an interface type of an exposed web service interface on the web services endpoint; translate the received web services request to be compliant with the determined interface type if the determined interface type is not already compliant with the first web services format; send a compliant web services request to the web services endpoint; receive a response from the web services endpoint; translate the response to be compliant with the first web services format if the response is not already compliant with the first web services format; and send a response, compliant with the first web services format, to the web services client.
 20. The computer system of claim 19, wherein the first web services format is SOAP and the determined interface type is RESTful.
 21. The computer system of claim 19, wherein the first web services format is RESTful and the determined interface type is SOAP.
 22. A computer network comprising: a plurality of processing units communicatively coupled to a computer network; a first processing unit configured to perform at least a portion of the method of claim 1 wherein the entire method of claim 1 is performed collectively by the plurality of processing units.
 23. A computer network comprising: a plurality of processing units communicatively coupled to a computer network; a first processing unit configured to perform at least a portion of the method of claim 7 wherein the entire method of claim 7 is performed collectively by the plurality of processing units. 